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With the usage of NOS in the Tampa Bay area, we have found the need to link between 
NOS users using the ROSE network. Like other areas where ROSE is used as the primary 
networking system, up until a year ago, the only way to do so was using SLIP over TNC’s 
running in transparent mode. Manually setting up the link then issuing the slip connection to 
the distant IP facility. 


About a year ago Tom Moulton told us he was ready with code that would pass non $FO 
PID’s specifically to allow IP to pass over the ROSE network. Of course, NetRom or any 
other non $FO PID could be passed thereby allowing the identification of say packet voice, 
images, or whatever needed. 


As soon as we had the new code in our switches | started testing with other stations in the 
area to determine if what was promised would work. At first we found that the 
“JUMP-START” command and the ROSE link status messages would cause the NOS code 
to route the link being set up to the AX.25 BBS in NOS. We were able to circumvent this 
problem by turning off JUMP-START and using the “reliable” mode of ROSE, which does 
not generate the status messages. 


After setting up the initial links, we tested with KO4KS, N4ZXI and the TBARS BBS, and 
found that we were able to reliably exercise the different facilities in NOS, starting with the 
humble “PING” session and terminating with FTP and SMTP operations. 


A result of this testing was Brian, KO4KS including in his version of NOS (TNOS) a separate 
JP call, this call would take any non IP PID and disregard it, but it would respond to any 
links arriving with a IP PID, this action took care of the $FO PID problem, since TNOS has a 
separate call for AX.25 connects. 


Brian has worked to make TNOS more ROSE compliant, and has not had to do any major 
work there, the big advantage being that ROSE does not require a special driver like 
NetRom does, you do not have to “fake out” the ROSE switch with a PID it recognizes, you 
just pass on the IP PID. Brian tells me that this alone means that NOS could be reduced by 
about 40k in size, if NetRom did not have to be supported in this way. 


| also set up a Separate NOS system on a laptop so | could observe both sides of the link, 
mainly to determine what needed to be done on both the originating station and the 
terminating station. 


This link entered the ROSE network at the Tampa switch and exited at the Clearwater 
switch. (| can access both switches from my location.) The path took the data through 4 
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switches and over a very congested part of the old 220mhz flat network (which we are 
trying to abandon as soon as time and money permit). 


| found that a FTP would run quite well, | was able to take advantage of Phil Karn’s 
implementation of the "M" bit to send large IP frames which were fragmented at the AX.25 
level, sent over the network to the distant NOS system where the 1 k IP frame was 
reconstructed. 


Sending a IP frame of 1 k in size resulted in five 256 character frames at the AX.25 level, the 
first of which had the IP header and part of the data, the rest were data. The first 4 frames 
were sent with the ‘M’ Bit set and when the final frame was sent the 

‘M’ bit was flipped allowing the NOS system on the far end to reconstruct the 1 k IP frame. 


The usage of the ‘M’ bit and AX.25 fragmentation without added overhead is a great 
advantage over the present system used in most areas where IP is sent over NetRom (or 
it's clone TheNet) with 40 characters of IP header plus 20 characters of NetRom header 
making a total of 60 characters for each 256 character frame, leaving only 196 characters of 
space available for data. Adding this gain to that of the usage of the ‘M’ bit makes for a 
very efficient transfer of data between the two NOS boxes. 


The level 3 frames of ROSE add characters minimum of data to the level 3 | frames, and it 
is done transparently, in other words you do not have to subtract the ROSE overhead from 
your paclen and set accordingly, the ROSE frame is actually longer than 256 bytes by the 
number of level 3 bytes added to it. 


As a final test, at this time | periodically set up a SMTP session with K5JB in Oklahoma City, 
all carried over ROSE. | believe the number of switches on that path, counting those on the 
Tampa, FL Dallas, TX wormhole are about 15 switches. These sessions though slow (there 
is a bad path on the north end through a digipeater) do work, and ROSE passes the IP PID 
all the way from end to end. If for some reason there is a network failure TCP picks the link 
back up and finishes the job. 


Reviewing our findings; 


IP can and will work quite well over ROSE. The combination of the two systems has added 
benefits for both. 


Phil Karn’s usage of the ‘M’ bit in NOS allows NOS and ROSE to work hand in hand to 
reduce network overhead but to still keep the advantages that each brings to packet radio. 


With the implementation of the ‘M’ bit and PID transparency of ROSE we have a network 
that can reduce IP overhead and at the same time recover from a network failure, picking 
up where things left off. 


Brian Lantz, KO4KS has implemented several servers in TNOS, one of which is the INFO 
server, we are now routing certain types of calls to INFO in the Tampa area to that server, it 
allows us to give the user much more detailed information about the area facilities, also it is 


25 


set up such that it provides that information by title, so if a user is interested in only a part 
of the network, that user can select on that information he/she needs and not load up the 
network with useless data. 


The conference server found in NOS has also been worked over by Brian, he has also 
made it such that a quick WHO will tell you not only the usual information but also the 
ROSE X.121 if a link is arriving over a ROSE path, this lets you rapidly identify where those 
users are on the network. 


We have not yet been able to test the linking of two conference servers over ROSE yet, but 
such a link would be advantageous to all involved, the linked conference servers would 
reduce the number of frames going to users, at this time we have a lot of connects to the 
conference server from the Texas and Oklahoma area, if there was a conference server 
running out there it would mean that the network would only have to carry one copy of 
each frame between Tampa and Dallas, not one for each user. 


ROSE has a much better defined addressing system for a planet wide network IP handles 
the end user address quite well, the combination of the two gives a much more workable 
addressing system, reducing the need for IP addressing for simple switching facilities, and 
leaving these addresses available for end users to occupy. 


ROSE being based on CCITT X.121 addressing already has a global networking concept 
built into it, there is no need to use dwindling IP addresses for networking facilities, let 
ROSE take up that job and use the IP address as the address of the end facilities at each 
NOS or TCP user that really needs them. 


NetRom, TheNet sysops note, you can use ROSE as your backbone and keep your nodes 
at the front end for your users. When a link is established, it is done over ROSE, this has 
the advantage of not needing to limit the routes and nodes to only so many deep, you can 
then let your users use the old system (they would not need to learn the new one since 
they will be connecting to other nodes and out to the target station at the other end. You 
would of course need to use versions of TheNet which allow connects over digipeater 
paths, versions such as TheNet 2.10 will not allow this type of operation. 


The advantages gained by using one of these systems over a ROSE backbone are many, 
your nodes do not have to keep such a extensive list of nodes with your backbone being all 
ROSE only the exit points will be kept. If there is a network failure, ROSE will inform you of 
the area in which it took place and the type of failure. And if you choose to run another 
protocol over your backbone, ROSE with it’s PID transparency will allow you to do so, 
something that is not able to be done with TheNet/NetRom in it’s present form. 


1 believe the results of this work will show that the old protocol wars were fought for 
nothing, that like all things, you must pick and choose, and combine for a given application, 
here we have two systems, at one time opposites in our packet radio activity being joined, 
each for what it offers, both will come out the stronger for it, and the sum of the whole will 
be a powerful networking and user system offering very interesting possibilities for the future 
of Amateur Packet Radio. 
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There is one outstanding activity that | would like to do sometime, compare a similar 
NetRom link to the ones we have tested as described above. We do not have a NetRom 
network in this area, and I do not have the time to set up a simulation, perhaps we can do 
so in the future. 


